System design and development is known in the art. A customer will typically contract with a designer/manufacturer to design and develop a system. The customer typically provides top-level system requirements (i.e., required specifications) within the contract. However, these requirements describe the performance of the entire system, and systems are designed and developed as individual elements (e.g., components, sub-assemblies, circuit cards, software packages, etc.). Hence, requirements development is the process of defining the requirements of each of the individual system elements such that they all work together to form an optimum system level solution.
Complex systems require many different system elements to be developed at the same time and still be functional as large systems once integrated together. Hence, providing components at the lower end of the system tree (e.g., the individual components) that enable the required specifications to be satisfied (e.g., the overall system) is crucial to the design and manufacture of the system.
Traditionally, development programs have used a “bottom up” approach to assessing the effect that lower level allocations may have on a system. As is illustrated in FIG. 1, such traditional approach starts with a bottom level and, through trial and error, the impact that assumed allocations would have at higher levels is assessed, and the allocations are adjusted until the desired results are obtained.
As an example, FIG. 1 illustrates a typical specification tree 10, in this case relating to the development of a product, such as a weapons system, for example. The top-level requirements typically come from the customer contract. Next, specifications are developed for each major sub-program (e.g., the individual parts 12, the components 14 that include the parts 12, the sub assemblies 16 that include the components 14, the assemblies 18 that includes the sub-assemblies 16, and the product 20 that includes the assemblies 18). Next, assignments are made to component standard deviations based on expert judgment. These allocations then are run through a simulation or model and used to predict the probability of compliance of the system response with the required specifications. When this comparison fails, as it usually does, the user alters one or more component standard deviations and iterates until a solution is found. There is no guarantee that this process will ever find a solution, but in the hands of an expert, it will usually find an approximate solution. There is no way to know, however, whether one is near an optimal, best or cost effective solution.
With the above-described conventional approach, the emphasis is on determining a standard deviation for a lower level, and then iteratively evaluating how that standard deviation impacts the overall system. This leads to one drawback wherein the approach is slow in determining the requirements for each component and, thus, the system. Another drawback is that one cannot be certain that an optimal solution has been obtained.
Yet another drawback is that complex requirements are usually analyzed multiple times during flow-up from one level to the next. For example, a first set of analyses is done to determine the allocation of requirements at the component level 12 of the specification tree 10, then again to determine the allocation between the elements at the next level, and so on. Each time the analysis is repeated in increasing level of detail, in order to refine the requirements as they flow up through the system. However, repeating the analysis many times can be inefficient.